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INTRODUCTION 

Schedule conflicts occur when the demand for a resource exceeds the availability of that 
resource When a conflict occurs in a constraint relaxation domain, such as the Space 
Network (SN), an action must be taken to resolve the conflict. Providing alternative 
times, alternative resources, or a combination of the two, are methods of resolv g 
conflict These alternatives are then submitted to the requestor. If no alternative is 
acceptable, the request will be declined. This process is called conflict resolution. 

The purpose of this paper is to initiate a discussion of how the conflict resolution P r °cess at 
the Network Control Center can be made more efficient. The paper will describe how 
resource conflicts are currently resolved, describe impacts of automating .inflict 
resolution in the ATDRSS era, present a variety of conflict resolution strategies, a 
suggest discussion topics related to automated conflict resolution. 

CURRENT SPACE NETWORK CONFLICT RESOLUTION 

User POCCs transmit Schedule Add Requests (SARs) to the NCC by the beginning of the 
forecast period week. The forecast period begins fourteen days prior to the week »n which 
services are to be provided. Requests are ordered and placed on the schedule one by one 
until a conflict occurs. The request causing the conflict is placed in the declined queue^ 
When all requests have either been scheduled or declined, conflict negotiation begins 
serially, starting with the highest priority rejected request. Current conflict negotiation is 
a verbal, time consuming process between the Forecast Analyst and the representatives of 
the user POCCs. Because of security requirements, the user POCCs are not given access 
the entire schedule, so they cannot identify their own time and resource alternaUves^ 
Because of current system limitations, the Forecast Analyst has little automated 
information on user POCC requirements, scheduling aids, or Field of View, so it is 
difficult for the analyst to determine, other than through operational experience, which of 
the available alternatives will meet the needs of the user. 

Current NCC scheduling software, as with many scheduling systems, emphasizes conflict 
avoidance, rather than conflict resolution. Care is taken to place an event on the schedule 
in such a way as to avoid potential conflicts. Some of these algorithms include placing the 
event within tolerance where it will leave the largest gap of remaining unscheduled time, 
or a look-ahead metric which places the event to avoid conflict with remaining 
unscheduled events. The problem with this approach is that it looks at the puzzle instead o 
looking at the piece. In other words, there is no intelligence or knowledge of the 
applicability or preference of individual user conflict resolution strategies for each of the 
requests being placed on the schedule. Rather, the focus of scheduling is on the resources, 
keeping blocks of resource available time open for subsequent requests. 

Another difficulty with the current scheduling and conflict resolution process is that 
current SN service requests do not contain or utilize flexibility. Flexibility can be 
expressed in a request two ways. A request can include flexibility of start time by 
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specifying a plus or minus tolerance. A request can include flexibility of resource 
selection by specifying a configuration code which indicates 'open selection" for antenna 
and interface channel. Because of limitations in the scheduling message formats, the 
NCC software and the POCC scheduling software have caused users not to include time 
tolerance in their requests. Other network elements requirements have dictated that users 
specifically request certain resources instead of allowing the NCC to openly select them to 
avoid conflicts. 

In a typical schedule week, in which approximately 480 unclassified event requests were 
received by the NCC, about twenty percent of these requests resulted in schedule conflicts. 
Of that twenty percent, around sixty percent were resolved by alternate links, ten percent by 
slipping the start time, twenty percent by both slipping time and selecting an alternate 
link, and ten percent were deleted. The fact that ninety percent of the conflicts were 
resolvable indicates that there is flexibility in the users requirements which is not 
expressed in the request to the NCC. 

SN CONFLICT RESOLUTION IN THE ATDRSS ERA 

Because the number of service requests and ATDRSS users in the ATDRSS era (1997-2012) 
will increase three to ten fold, the number of resource conflicts will exceed the current 
ability to manually resolve them. If conflict resolution is performed one request at a time 
in priority order, the time required to resolve conflicts will be unacceptable. Automating 
the process will enable scheduling to be done in a more realistic time frame. To perform 
automated conflict resolution, information on how to resolve conflicts must be available. It 
can be identified by the user POCC in each specific service request, and/or be embedded in 
the knowledge of the NCC scheduling system. 

Embedding the Knowledge 

To perform automated conflict resolution, knowledge of user capabilities, user 
preferences, and SN resources could be embedded in the scheduling system. User 
capability data includes ATDRS to USAT and USAT to ATDRS field of view information, 
sun interference data, antenna patterns, and restrictions such as power availability that 
would limit antenna substitution. Knowledge about user preferences include mission 
characteristics affecting both flexibility in request parameters, service alternatives, and a 
weighted priority scheme for relaxing scheduling constraints. Knowledge of the SN 
includes resource availability, resource capability, RFI, to include antenna pattern 
overlap of scheduled USATs, and antenna slew time. 

Using the above knowledge, a conflict resolution profile could be created by the NCC for 
each user POCC service request defining a hierarchy of conflict resolution strategies 
applicable in each instance to the particular user spacecraft, service parameter tolerances, 
and dependencies between spacecraft services. The hierarchy would indicate the types of 
strategies to be used to resolve conflicts and the order in which they should be used. 

The knowledge about the specific user conflict resolution preferences could be input to the 
NCC scheduling system by the user POCC during service planning similar to a generic 
scheduling concept, elicited from scheduling experts at the NCC, and/or learned by the 
system during analyst-in-the-loop conflict negotiation. 

User Specifying the Knowledge 
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An alternative to embedding all the knowledge in the NCC scheduling system is to include 
the information affecting conflict resolution strategies in the service request from the user 
POCC The user could request a specific event (time and link) as the preferre servic . 
The user could also request subsequent ordered choices if the first preference is not 
available. The user could prioritize request parameters. For example a specific start time 
may be prefered over a specific TDRS. In addition, the user could specify in the request that 
no strategies be used (feast or famine). The information exchange necessary for both 
automated and manual conflict resolution could be facilitated by implementation of a 
Space Network User Pocc Interface (SNUPI) workstation in which schedule and _ service 
flexibility could be graphically displayed and communicated simultaneously at the NCC 

and user POCC. 


Factors Affecting Conflict Resolution 


In addition to user preference, the order and precedence of conflict resolution strategies 
may be influenced by organizational and operational goals. Candidate organizational 
goals affecting conflict resolution are: 


NASA established user POCC priority. This places more emphasis on the higher 
priority users getting their first preference for conflict resolution strategies. 


Resource utilization schemes. The NCC may wish that certain users be assigned 
specific ATDRS or ATDRS links. The NCC may wish to avoid scheduling on one 
satellite, for example, the spare, except when no other conflict resolution strategy 
will work. The NCC may wish to maximize utilization of single resources, or 
ensure a leveling of resource utilization across the system. Each of these schemes 
would impact the application of conflict resolution strategies. 


Rewarding cooperation. The NCC may use priority in conflict resolution to reward 
a user POCC for following the SN rules. For example, the POCC that always has 
requests in on time, has maximum flexibility in each request, or is willing to give 
up a service during a conflict, may be rewarded in future scheduling by increasing 
the priority of its conflict resolution strategies. 


In an effort to achieve schedule stability, there may be operational limitations that affect 
the application of conflict resolution strategies. 

Development (forecast) period. All applicable strategies would be used on all 
requests. 

Maintenance period. Strategies that go beyond specific request tolerances for 
scheduled requests would not used, but all applicable strategies would be used for a 
request added in this period. Within twenty four hours of a service, no strategies 
would be used on previously scheduled requests. 


Spacecraft emergencies. All applicable strategies would be used to ensure the 
emergency is scheduled without conflict. 


Schedule Alternatives 


If conflict resolution is possible by performing a service in an alternative manner, 
generated through knowledge embedded in the NCC scheduling system, the alternative 
must be approved by the user POCC. For example, the user POCC may have requested an 
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SSA forward service that can be satisfied only by substituting an available SMA forward 
service. The knowledge in the system indicates that for an SSA conflict, the user satellite 
is capable of receiving the SMA forward, and the user POCC has accepted the SMA forward 
alternative in the past, but the service duration must be increased. The system checks 
Field of View data to determine if the longer duration service is applicable to the user 
satellite. The knowledge in the system may also indicate whether such a substitution is 
possible without advanced user confirmation. In either case, the alternative would be 
communicated to the user for confirmation before or after scheduling. 

Manual Conflict Resolution 

In spite of automating the conflict resolution process, special circumstances will occur in 
the ATDRSS era requiring manual conflict resolution by the SN scheduling analyst. 
Examples include when two user POCCs having the same priority (Space Station and Space 
Shuttle) have a resource conflict, when spacecraft emergencies conflict with higher 
priority user POCC schedules, or when a service bumps a lower priority user POCC less 
than twenty-four hours before the service. The analyst will have the capability to 
manually move, fix, or delete a service request from the system. Once a service conflict is 
manually resolved by the analyst, it cannot be moved as part of further automatic conflict 
resolution until the analyst removes the override. 

CONFLICT RESOLUTION STRATEGIES 

In order to resolve conflicts, there must be conflict resolution strategies. Potential 
strategies include: 

(1) Priority. The user POCC having the highest priority established by NASA for 
both spacecraft and mission, will have its service placed on the schedule ahead of a 
lower priority user service. Goodness of schedule may be determined by how many 
highest priority user services are placed on the schedule using the highest priority 
conflict resolution strategy. 

(2) Moving a service in time, by moving the request start time forward or 
backward within a tolerance window. 

(3) Moving a service to the previous or next valid view period appropriate for that 
spacecraft. 

(4) Switching to an alternate resource. If the request can be satisfied by a resource 
not specifically requested, the requested but unavailable resource may be replaced 
by the alternate, available resource. An example might be an MA forward service 
replacing an unavailable SSA forward service. 

(5) Shrinking a service duration. It may be acceptable to decrease the duration of a 
service by a few minutes in order to allow it to fit on the schedule, as an alternative 
to denying the service request. After a service has been shrunk, it may be moved 
forward or backward within tolerance. This may be particularly applicable to 
forward services which currently schedule more time than is normally used. 

(6) Breaking up a prototype event into individual services, and performing 
separate conflict resolution strategies on the individual services. Relationships 
between services, both temporal and logical, must be specified, and considered so 
that individual conflict resolution does not invalidate the entire requested event. 
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(7) Breaking up a service into multiple discontinuous services, or gapping It may 
be acceptable to break up a requested service into two shorter services separate y a 
small, conflicting higher priority request. An example of such a service may be a 
tape playback that can be interrupted and resumed. 

(8) Combinations of the above strategies. 

(9) Deleting a service from the schedule. A higher priority request may be 
scheduled by deleting a lower priority request from the schedule, eliminating 
conflict. 

AUTOMATED CONFLICT RESOLUTION IMPLEMENTATIONS 

Some of the automated conflict resolution concepts mentioned here are already 
implemented in existing scheduling systems. 

Plan-IT-2 developed by the Jet Propulsion Laboratory allows the scheduling analyst to 
explicitly invoke tactical plans for automatic scheduling, or read them ,n from a script 
file. The conflict resolution tactics specify what strategies to implement and in what 

order. 

The Experiment Scheduling Program <ESP)2, developed at Marshall Space Flight Center, 
allows users to specify weighting factors for each of the parameters in a schedule rcqucsL 
In this way, preferences can be specified for order of application, and the goodness of the 
resultant schedule can be quantified by the sum of the weights. 

DISCUSSION TOPICS 

The following issues relevant to this paper should be discussed during the working 
session: 

What specific conflict resolution strategies are applicable to the user POCCs? 

How much would conflict resolution strategies and preferences vary between services o 

Ho e w r much er w P ould C Connict resolution strategies and preferences vary between different 
user POCCs? 

Does a hierarchy of strategy preferences exist? 

Under what circumstances should manual conflict resolution be required. 

How amenable to automatic conflict resolution are user POCCs? 

How much and what type of tolerance could be communicated to the NCCfrom user I OCCs. 
How much would tolerances vary between services of a specific user I Utb. 
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